home *** CD-ROM | disk | FTP | other *** search
/ Total Network Tools 2002 / NextStepPublishing-TotalNetworkTools2002-Win95.iso / Archive / Misc Servers / Zope.exe / ACCESSCONTROL.TXT < prev    next >
Encoding:
Text File  |  1997-12-31  |  6.3 KB  |  253 lines
  1. Security Architecture
  2. ---------------------
  3.  
  4. Users
  5. -----
  6.  
  7. Objects representing users may be created in Principia
  8. User Folder objects. User objects maintain the information
  9. used to authenticate users, and allow roles to be associated
  10. with a user.
  11.  
  12.  
  13.  
  14. Permissions
  15. -----------
  16.  
  17. A "permission" is the smallest unit of access to an object,
  18. roughly equivalent to the atomic permissions seen in NT:
  19. R (Read), W(Write), X(Execute), etc. In Principia, a permission
  20. usually describes a fine-grained logical operation on an object,
  21. such as "View Management Screens", "Add Properties", etc.
  22.  
  23. Different types of objects will define different permissions
  24. as appropriate for the object.
  25.  
  26.  
  27.  
  28. Types of access
  29. ---------------
  30.  
  31. A "type of access" is a named grouping of 0 or more of the
  32. permissions defined by an object. All objects have one predefined
  33. type of access called Full Access (all permissions defined by that 
  34. object). A user who has the special role "Manager" always has Full 
  35. Access to all objects at or below the level in the object hierarchy 
  36. at which the user is defined.
  37.  
  38. New types of access may be defined as combinations of the
  39. various permissions defined by a given object. These new
  40. types of access may be defined by the programmer, or by
  41. users at runtime. 
  42.  
  43.  
  44.  
  45.  
  46. Roles
  47. -----
  48.  
  49. A role is a name that ties users (authentication of identity)
  50. to permissions (authorization for that identity) in the system.
  51. Roles may be defined in any Folder (or Folderish) object in the
  52. system. Sub folders can make use of roles defined higher in the
  53. hierarchy. These roles can be assigned to users. All users, 
  54. including non-authenticated users have the built-in role of 
  55. "Anonymous". 
  56.  
  57. Principia objects allow the association of defined roles 
  58. with a single "type of access" each, in the context of that 
  59. object. A single role is associated with one and only one 
  60. type of access in the context of a given object.
  61.  
  62.  
  63.  
  64. Examples
  65. --------
  66.  
  67.   User                        Object1
  68.  
  69.   o has the role "RoleA"      o has given "RoleA" Full Access
  70.  
  71.   Result: the user has Full Access to Object1.
  72.  
  73.  
  74.  
  75.   User                        Object2
  76.   o has the role "RoleA"      o has given "RoleB" Full Access
  77.  
  78.                               o has given the role "RoleA" View Access,
  79.                                 a custom type of access that allows only
  80.                                 viewing of the object.
  81.  
  82.   Result: the user has only View Access.
  83.  
  84.  
  85.  
  86. Notes
  87. -----
  88.  
  89. All objects define a permission called "Default permission". If this
  90. permission is given to a role, users with that role will be able to
  91. access subobjects which do not explicitly restrict access.
  92.  
  93.  
  94.  
  95. Technical
  96. ---------
  97.  
  98. Objects define their permissions as logical operations.
  99. Programmers have to determine the appropriate operations
  100. for their object type, and provide a mapping of permission
  101. name to attribute names. It is important to note that permissions
  102. cannot overlap - none of the attributes named in a permission
  103. can occur in any of the other permissions. The following are
  104. proposed permissions for some current principia objects:
  105.  
  106.  
  107. Folder
  108.   o View management screens
  109.   o Change permissions
  110.   o Undo changes
  111.   o Add objects
  112.   o Delete objects
  113.   o Add properties
  114.   o Change properties
  115.   o Delete properties
  116.   o Default permission
  117.  
  118. Confera Topic
  119.   o View management screens
  120.   o Change permissions
  121.   o Undo changes
  122.   o Add objects
  123.   o Delete objects
  124.   o Add properties
  125.   o Change properties
  126.   o Delete properties
  127.   o Default permission
  128.   o Change Configuration
  129.   o Add Messages
  130.   o Change Messages
  131.   o Delete Messages
  132.  
  133. Tabula Collection
  134.   o View management screens
  135.   o Change permissions
  136.   o Undo changes
  137.   o Add objects
  138.   o Delete objects
  139.   o Add properties
  140.   o Change properties
  141.   o Delete properties
  142.   o Default permission
  143.   o Change schema
  144.   o Upload data
  145.   o Add computed fields
  146.   o Change computed fields
  147.   o Delete computed fields
  148.  
  149. Document/Image/File
  150.   o View management screens
  151.   o Change permissions
  152.   o Change/upload data
  153.   o View
  154.  
  155. Session
  156.   o View management screens
  157.   o Change permissions
  158.   o Change session config
  159.   o Join/leave session
  160.   o Save/discard session
  161.  
  162. Mail Host
  163.   o View management screens
  164.   o Change permissions
  165.   o Change configuration
  166.  
  167.  
  168.  
  169.  
  170. To support the architecture, developers must derive an
  171. object from the AccessControl.RoleManager mixin class,
  172. and define in their class an __ac_permissions__ attribute.
  173.  
  174. This should be a tuple of tuples, where each tuple represents
  175. a permission and contains a string permission name as its first
  176. element and a list of attribute names as its second element.
  177.  
  178. Example:
  179.  
  180.     __ac_permissions__=(
  181.  
  182.     ('View management screens',
  183.      ['manage','manage_menu','manage_main','manage_copyright',
  184.       'manage_tabs','manage_propertiesForm','manage_UndoForm']),
  185.     ('Undo changes',       ['manage_undo_transactions']),
  186.     ('Change permissions', ['manage_access']),
  187.     ('Add objects',        ['manage_addObject']),
  188.     ('Delete objects',     ['manage_delObjects']),
  189.     ('Add properties',     ['manage_addProperty']),
  190.     ('Change properties',  ['manage_editProperties']),
  191.     ('Delete properties',  ['manage_delProperties']),
  192.     ('Default permission', ['']),
  193.     )
  194.    
  195.  
  196.  
  197. The developer may also predefine useful types of access, by
  198. specifying an __ac_types__ attribute. This should be a tuple of 
  199. tuples, where each tuple represents a type of access and contains 
  200. a string name as its first element and a list of permission names 
  201. as its second element.
  202.  
  203. By default, only "Full Access" is defined (by the RoleManager mixin).
  204. If you wish to override __ac_types__ to provide convenient types of
  205. access, you must always be sure to define "Full Access" as containing 
  206. the names of all possible permissions for your object.
  207.  
  208. Example:
  209.  
  210.     __ac_types__=(
  211.  
  212.     ('Full Access', map(lambda x: x[0], __ac_permissions__)),
  213.     ('Change', ['Add Objects', 'Add Properties', 'Change Properties']),
  214.  
  215.     )
  216.  
  217.  
  218.  
  219. Developers may also provide pre-defined role names that are
  220. not deletable via the interface by specifying an __ac_roles__
  221. attribute. This is probably not something we'll ever use under
  222. the new architecture, but it's there if you need it.
  223.  
  224. Example:
  225.  
  226.     __ac_roles__=('Manager', 'Anonymous')
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.